curl --request POST \
--url https://api.zelinqa.ai/v1/next-questions \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '
{
"session_id": "<string>",
"conversation_history": [
{
"content": "<string>"
}
],
"context": "<string>",
"answered_question_ids": [
"<string>"
]
}
'import requests
url = "https://api.zelinqa.ai/v1/next-questions"
payload = {
"session_id": "<string>",
"conversation_history": [{ "content": "<string>" }],
"context": "<string>",
"answered_question_ids": ["<string>"]
}
headers = {
"Authorization": "Bearer <token>",
"Content-Type": "application/json"
}
response = requests.post(url, json=payload, headers=headers)
print(response.text)const options = {
method: 'POST',
headers: {Authorization: 'Bearer <token>', 'Content-Type': 'application/json'},
body: JSON.stringify({
session_id: '<string>',
conversation_history: [{content: '<string>'}],
context: '<string>',
answered_question_ids: ['<string>']
})
};
fetch('https://api.zelinqa.ai/v1/next-questions', options)
.then(res => res.json())
.then(res => console.log(res))
.catch(err => console.error(err));{
"next_question": {
"external_id": "<string>",
"text": "<string>"
},
"exhausted": true,
"nbq_version": "<string>",
"request_id": "<string>"
}{
"code": "unauthorized",
"message": "Clé d'intégration absente ou invalide.",
"request_id": "req_9000",
"details": {}
}{
"code": "insufficient_scope",
"message": "Cette clé ne permet pas de publier une configuration.",
"request_id": "req_9001",
"details": {
"required_scopes": [
"configuration:publish"
],
"granted_scopes": [
"configuration:read",
"configuration:write"
]
}
}[Déprécié 0.9] Calculer la question suivante sans session serveur
Route de la bêta 0.9, conservée pour ne pas casser les intégrations existantes. Elle reste servie à l’identique et n’évolue plus.
Différence structurante avec la V1 : ici le client fournit lui-même
session_id et renvoie l’historique à chaque appel ; le moteur ne conserve
aucun état. En V1, NBQ alloue la session via POST /v1/sessions et maintient
l’état canonique côté serveur.
Remplacée par POST /v1/sessions/{session_id}/next. Correspondance champ à
champ dans docs/api-compat-0.9-to-v1.md.
Une date de retrait sera annoncée ultérieurement par un en-tête Sunset sur
cette route ; elle n’est pas fixée dans ce contrat.
curl --request POST \
--url https://api.zelinqa.ai/v1/next-questions \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '
{
"session_id": "<string>",
"conversation_history": [
{
"content": "<string>"
}
],
"context": "<string>",
"answered_question_ids": [
"<string>"
]
}
'import requests
url = "https://api.zelinqa.ai/v1/next-questions"
payload = {
"session_id": "<string>",
"conversation_history": [{ "content": "<string>" }],
"context": "<string>",
"answered_question_ids": ["<string>"]
}
headers = {
"Authorization": "Bearer <token>",
"Content-Type": "application/json"
}
response = requests.post(url, json=payload, headers=headers)
print(response.text)const options = {
method: 'POST',
headers: {Authorization: 'Bearer <token>', 'Content-Type': 'application/json'},
body: JSON.stringify({
session_id: '<string>',
conversation_history: [{content: '<string>'}],
context: '<string>',
answered_question_ids: ['<string>']
})
};
fetch('https://api.zelinqa.ai/v1/next-questions', options)
.then(res => res.json())
.then(res => console.log(res))
.catch(err => console.error(err));{
"next_question": {
"external_id": "<string>",
"text": "<string>"
},
"exhausted": true,
"nbq_version": "<string>",
"request_id": "<string>"
}{
"code": "unauthorized",
"message": "Clé d'intégration absente ou invalide.",
"request_id": "req_9000",
"details": {}
}{
"code": "insufficient_scope",
"message": "Cette clé ne permet pas de publier une configuration.",
"request_id": "req_9001",
"details": {
"required_scopes": [
"configuration:publish"
],
"granted_scopes": [
"configuration:read",
"configuration:write"
]
}
}Autorisations
Clé d'intégration préfixée nbq_live_, envoyée dans
Authorization: Bearer nbq_live_… et résolue par l'authorizer Lambda de
l'API Gateway publique. L'authorizer valide la clé, puis injecte en amont
du service les headers de contexte x-tenant-id, x-nbq-id et x-scopes —
x-scopes étant la liste des scopes de la clé séparés par des virgules,
par exemple runtime,configuration:read.
Ces headers ne sont jamais acceptés depuis le client : toute valeur entrante
est écrasée. Une clé absente ou invalide produit 401 au niveau de la
passerelle ; une clé valide sans le scope requis produit 403 avec le code
insufficient_scope.
Corps
Identifiant choisi par le client, contrairement à la V1 où NBQ l'attribue.
1 - 12850Show child attributes
Show child attributes
8000200